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Abstract 


This document describes architectural considerations and implications related to the use of a 
Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN 
architecture can change when an NRS is utilized and howits use influences the ICN routing 
system. This document is a product of the Information-Centric Networking Research Group 
(ICNRG). 
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1. Introduction 


Information-Centric Networking (ICN) is an approach to evolving the Internet infrastructure to 
provide direct access to Named Data Objects (NDOs) by names. In two common ICN 
architectures, Named Data Networking (NDN) [NDN] and Content-Centric Networking (CCNx) 
[CCNx], the name of an NDO is used directly to route a request to retrieve the data object. Such 
direct name-based routing has inherent challenges in enabling a globally scalable routing system, 
accommodating producer mobility, and supporting off-path caching. These specific issues are 
discussed in detail in Section 3. In order to address these challenges, a Name Resolution Service 
(NRS) has been utilized in the literature as well as the proposals of several ICN projects 
[Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan]. 
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This document describes the potential changes in the ICN architecture caused by the introduction 
of an NRS and the corresponding implication to the ICN routing system. It also describes ICN 
architectural considerations for the integration of an NRS. The scope of this document includes 
considerations from the perspective of an ICN architecture and routing system when using an 
NRS in ICN. A description of the NRS itself is provided in the companion NRS design 
considerations document [RFC9138], which provides the NRS approaches, functions, and design 
considerations. 


This document represents the consensus of the Information-Centric Networking Research Group 
(ICNRG). It has been reviewed extensively by the Research Group (RG) members who are actively 
involved in the research and development of the technology covered by this document. It is not 
an IETF product and is not a standard. 


2. Terminology 


Name Resolution Service (NRS): An NRS in ICN is defined as a service that provides the function 
of translating a content name or a data object name into some other information suchasa 
routable prefix, a locator, an off-path-cache pointer, or an alias name that is more amenable 
than the input name to forwarding the object request toward the target destination storing the 
NDO [RFC9138]. An NRS is most likely implemented through the use of a distributed mapping 
database system. The Domain Name System (DNS) may be used as an NRS. However, in this 
case, the requirements of frequent updates of NRS records due to the creations of a lot of new 
NDOs and changes in their locations in the network need to be considered. 


NRS server: An NRS comprises the distributed NRS servers storing the mapping records in their 
databases. NRS servers store and maintain the mapping records that keep the mappings of 
content or object name to some other information that is used for forwarding the content 
request or the content itself. 


NRS resolver: The client-side function of an NRS is called an NRS resolver. The NRS resolver is 
responsible for initiating name resolution request queries that ultimately lead to a name 
resolution of the target data objects. NRS resolvers can be located in the consumer (or client) 
nodes and/or ICN routers. An NRS resolver may also cache the mapping records obtained 
through the name resolution for later usage. 


Name registration: In order to populate the NRS, the content names and their mapping records 
must be registered in the NRS system by a publisher who has access rights to at least one 
authoritative NRS server or by a producer who generates named data objects. The records 
contain the mapping of an object name to some information suchas other alias names, 
routable prefixes, and locators, which are used for forwarding the content request. Thus, a 
publisher or producer of content creates an NRS registration request and sends it to an NRS 
server. On registration, the NRS server stores (or updates) the name mapping record in the 
database and sends an acknowledgement back to the producer or publisher that made the 
registration request. 
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Name resolution: Name resolution is the main function of the NRS system. It is performed by an 
NRS resolver, which can be deployed on a consumer node or an ICN router. Resolvers are 
responsible for either returning a cached mapping record (whose lifetime has not expired) or 
alternatively sending a name resolution request toward an NRS server. The NRS server 
searches for the content name in its mapping record database and, if found, retrieves the 
mapping record and returns it in a name resolution response message to the NRS resolver. 


NRS node: NRS servers are also referred to as NRS nodes that maintain the name records. The 
terms are used interchangeably. 


NRS client: Anode that uses the NRS is called an NRS client. Any node that initiates a name 
registration, resolution, or update procedure is an NRS client; that is, NRS resolvers, ICN client 
nodes, ICN routers, or producers can be NRS clients. 


3. Background 


A pure name-based routing approach in ICN has inherent challenges in enabling a globally 
scalable routing system, accommodating producer mobility, and supporting off-path caching. In 
order to address these challenges, an NRS has been utilized in proposals and literature of several 
ICN projects as follows: 


Routing scalability: In ICN, application names identifying content are intended to be used 
directly for packet delivery, so ICN routers run a name-based routing protocol to build name- 
based routing and forwarding tables. Similar to the scalability challenge of IP routing, if non- 
aggregatable name prefixes are injected into the Default Route Free Zone (DFZ) of ICN routers, 
they would be driving the uncontrolled growth of the DFZ routing table size. Thus, providing 
the level of indirection enabled by an NRS in ICN can be an approach to keeping the routing 
table size under control. The NRS system resolves name prefixes that do not exist in the DFZ 
forwarding table into globally routable prefixes such as the one proposed in NDN [Afanasyev]. 
Another approach dealing with routing scalability is the Multi-level Distributed Hash Table 
(MDHT) used in NetInf [Dannewitz]. It provides name-based anycast routing that can support 
a non-hierarchical namespace and can be adopted on a global scale [Dannewitz2]. 


Producer mobility: In ICN,ifa producer moves into a different name domain that uses a 
different name prefix, the request for a content produced by the moving producer with the 
origin content name must be forwarded to the moving producer's new location. Especially in 
a hierarchical naming scheme, producer mobility support is much harder than in a flat 
naming scheme since the routing tables in a broader area need to be updated to track the 
producer movement. Therefore, various ICN architectures such as NetInf [Dannewitz] and 
MobilityFirst [MF] have adopted NRS systems to tackle the issues of producers whose location 
changes. 


Off-path caching: In-network caching is a common feature of an ICN architecture. Caching 
approaches can be categorized into on-path caching and off-path caching, according to the 
location of caches in relation to the forwarding path from the original content store toa 
consumer. Off-path caching, sometimes also referred to as content replication or content 
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storing, aims to replicate a Named Data Object in various locations within a network in order 
to increase the availability of content, reduce access latency, or both. These caching locations 
may not be lying along the content forwarding path. Thus, finding off-path cached content 
requires more complex forwarding procedures if a pure name-based routing is employed. In 
order to support access to off-path caches, the locations of replicas are usually advertised into 
a name-based routing system or into an NRS as described in [Bayhan]. 


This document discusses architectural considerations and implications of ICN when an NRS is 
utilized to solve such challenges facing a name-based routing in ICN. 


4. Implications of an NRS in ICN 


An NRS is not a mandatory part of an ICN architecture, as the majority of ICN architectures uses 
name-based routing that avoids the need for a name resolution procedure. Therefore, the 
utilization of an NRS in an ICN architecture changes some architectural aspects at least with 
respect to forwarding procedures, latency, and security, as discussed below: 


Forwarding procedure: When an NRS is included in an ICN architecture, the name resolution 
procedure has to be included in the ICN overall routing and forwarding architectural 
procedures. To integrate an NRS into an ICN architecture, there are certain things that have to 
be decided and specified such as where, when, and how the name resolution task is performed. 


Latency: When an NRSis included in an ICN architecture, additional latency introduced by the 
name resolution process is incurred by the routing and forwarding system. Although the 
latency due to the name resolution is added, the total latency of individual requests being 
served could be lower if the nearest copies or off-path caches can be located by the NRS lookup 
procedure. Additionally, there might be a favorable trade-off between the name resolution 
latency and inter-domain traffic reduction by finding the nearest off-path cached copy of the 
content. Finding the nearest cache holding the content might significantly reduce the content 
discovery as well as delivery latency. 


Security: When any newcomponent such as an NRS is introduced in the ICN architecture, the 
attack surface may increase. Protection of the NRS system itself against attacks such as 
Distributed Denial of Service (DDoS) and spoofing or alteration of name mapping records and 
related signaling messages may be challenging. 


5. ICN Architectural Considerations for NRS 


This section discusses the various items that can be considered from the perspective of ICN 
architecture when employing an NRS system. These items are related to the registration, 
resolution, and update of name mapping records, protocols and messages, and integration with 
the routing system. 


Hong, et al. Informational Page 5 


RFC 9236 Arch Considerations of ICN Using NRS April 2022 


5.1. Name Mapping Records Registration, Resolution, and Update 


When an NRS is integrated in ICN architecture, the functions related to the registration, 
resolution, and update of name mapping records have to be considered. The NRS nodes maintain 
the name mapping records and may exist as an overlay network over the ICN routers, that is, they 
communicate to each other through ICN routers. Figure 1 shows the NRS nodes and NRS clients 
connected through an underlying network. The NRS nodes should be deployed in such a manner 
that an NRS node is always available at a short distance from an NRS client so that 
communication latency for the name registration and resolution requested by the NRS client 
remains very low. The name registration, name resolution, and name record update procedures 
are briefly discussed below. 


+------------ + +------------ + 
| NRS Node | | NRS Node | 
+------------ + +------------ + 

| | 
| | 

+------------ + | | +------------ + 

IENRSACLi emt E ee ee | NRS Client | 

pope ans Ses + underlying network Bt tt + 


Figure 1: NRS Nodes and NRS Clients Connected through an Underlying Network 


Name registration: Name registration is performed by the producer (as an NRS client) when it 
creates a new content. When a producer creates content and assigns a name from its name 
prefix space to the content, the producer performs the name registration in an NRS node. 
Name registration may be performed by an ICN router when the ICN architecture supports off- 
path caching or cooperative caching since involving an NRS may be a good idea for off-path 
caching. The ICN routers with forwarder caches do not require name registration for their 
cached content because they lie on the path toward an upstream content store or producer. 
They will be hit when a future request is forwarded to the content producer by an ICN router 
lying downstream toward the ICN client node. However, ICN routers performing off-path 
caching of content must invoke the name registration procedure so that other ICN routers can 
depend on name resolutions to know about the off-path cache locations. If a content gets 
cached in many off-path ICN routers, all of them may register the same content names in the 
same NRS node, resulting in multiple registration actions. In this case, the NRS node adds the 
new location of the content to the name record together with the previous locations. In this 
way, each of the name records stored in the NRS node may contain multiple locations of the 
content. Assigning validity time or a lifetime of each mapping record may be considered 
especially for the off-path caching content and managing mobility. 


Name resolution: Name resolution is performed by an NRS client to obtain the name record 
from an NRS node by sending a name resolution request message and getting a response 
containing the record. In the name-based ICN routing context, the name resolution is needed 
by any ICN router whose forwarding information base (FIB) does not contain the requested 
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name prefix. Name resolution may also be performed by the consumer (especially in the case 
where the consumer is multihomed) to forward the content request in a better direction so 
that it obtains the content from the nearest cache. If the consumer is single homed, it may not 
bother to perform name resolution, instead depending on either straightforward name-based 
routing or name resolution by an upstream ICN router. In this case, the consumer creates the 
content request packet containing the content name and forwards to the nearest ICN router. 
The ICN router checks its FIB table to see where to forward the content request. If the ICN 
router fails to identify whether the requested content is reachable, it performs name 
resolution to obtain the name mapping record and adds this information to its FIB. The ICN 
router may also perform name resolution even before the arrival of a content request to use 
the name mapping record to configure its FIB. 


Name record update: Name record update is carried out when a content name mapping record 
changes, e.g., the content is not available in one or more of the previous locations. The name 
record update includes the substitution and deletion of the name mapping records. The name 
record update may take place explicitly by the exchange of name record update messages or 
implicitly when a timeout occurs and a name record is deemed to be invalid. The implicit 
update is possible when each record is accompanied by a lifetime value. The lifetime can be 
renewed only by the authoritative producer or node. The cached mapping records get erased 
after the lifetime expires unless a lifetime extension indication is obtained from the 
authoritative producer. 


5.2. Protocols and Semantics 


In order to develop an NRS system within a local ICN network domain or global ICN network 
domain, new protocols and semantics must be designed and implemented to manage and 
resolve names among different namespaces. 


One way of implementing an NRS for CCNx is by extending the basic TLV format and semantics 
[RFC8569] [RFC8609]. For instance, name resolution and response messages can be implemented 
by defining new type fields in the Interest and Content Object messages [CCNXNRS]. By leveraging 
the existing CCNx Interest and Content Object packets for name resolution and registration, the 
NRS system can be deployed with a fewICN protocol changes. However, because of confining the 
changes to the basic ICN protocol and semantics, the NRS system may not be able to exploit more 
flexible and scalable designs. 


On the other hand, an NRS system can be designed independently with its own protocol and 
semantics like the NRS system described in [Hong]. For instance, the NRS protocol and messages 
can be implemented by using a RESTful API, and the NRS can be operated as an application 
protocol independent of the rest of the ICN protocol. 
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5.3. Routing System 


An NRS reduces the routing complexity of ICN architecture compared to pure name-based 
routing. It does so by permitting the routing system to update the routing table on demand with 
the help of name records obtained from NRS. The routing system therefore needs to make name 
resolution requests and process the information returned, such as a prefix, a locator, an off-path- 
cache pointer, or an alias name, obtained from the name resolution. 


No matter what kind of information is obtained from the name resolution, as long as it is in the 
form of a name, the content request message in the routing system may be reformatted with the 
obtained information. In this case, the content name requested originally by a consumer needs 
to be involved in the reformatted content request to check the integrity of the binding between 
the name and the requested content. In other words, the information obtained from the name 
resolution is used to forward the content request, and the original content name requested by a 
consumer is used to identify the content. Alternatively, the resolved information may be used to 
build the routing table. 


The information obtained from name resolution may not be in the form of a name. For example, 
it may identify tunnel endpoints by IP address and instead be used to construct an IP protocol 
tunnel through which to forward the content request. 


6. Conclusion 


A Name Resolution Service (NRS) is not a mandatory part in an ICN architecture, as the majority 
of ICN architectures use name-based routing that does not employ a name resolution procedure. 
However, such name-based routing in ICN has inherent challenges in enabling a globally scalable 
routing system, accommodating producer mobility, and supporting off-path caching. In order to 
address these challenges, an NRS system has been introduced in several ICN projects. Therefore, 
this document describes how the ICN architecture changes when an NRS is utilized and how this 
affects the ICN routing system. 


The document defines a few terminologies related to an NRS and explains some inherent 
challenges of pure name-based routing in ICN such as routing scalability, producer mobility, and 
off-path caching. This document describes how the ICN architecture would change with respect to 
procedures, latency, and security when an NRS is utilized. According to the ICN architectural 
changes, this document describes ICN architectural considerations for NRS such as the functions 
related to the registration, resolution and update of name mapping records, protocols and 
semantics to implement an NRS system, and the routing system involving the name resolution. 


7. IANA Considerations 


This document has no IANA actions. 
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8. Security Considerations 


When any new component suchas an NRS is introduced in the ICN architecture, the attack 
surface increases. The related security vulnerability issues are discussed below: 


Namespace security: In order to deploy an NRS system in ICN architecture, ICN namespaces, 
which may be assigned by authoritative entities, must be securely mapped to the content 
publishers and securely managed by them. According to the ICN research challenges 
[RFC7927], a new namespace can also provide an integrity verification function to 
authenticate its publisher. The issues of namespace authentication and the mapping among 
different namespaces require further investigation. 


NRS system security: An NRS requires the deployment of new entities (e.g., NRS servers) to build 
distributed and scalable NRS systems. Thus, the entities, e.g., an NRS server maintaining a 
mapping database, could be the focus of attacks by receiving malicious requests from 
innumerable adversaries comprising of Denial-of-Service or Distributed-Denial-of-Service 
attacks. In addition, NRS clients in general must trust the NRS nodes in other network 
domains to some degree, and communication among them must also be protected securely to 
prevent malicious entities from participating in this communication. The history of name 
resolution data requires to be stored and analyzed as in passive DNS to uncover potential 
security incidents or discover malicious infrastructures. 


NRS protocol and message security: In an NRS system, the protocols to generate, transmit, and 
receive NRS messages related to the name registration, resolution, and record update should 
be protected by proper security mechanisms. Proper security measures must be provided so 
that only legitimate nodes can initiate and read NRS messages. These messages must be 
secured by integrity protection and authentication mechanisms so that unauthorized parties 
cannot manipulate them when being forwarded through the network. Security measures to 
encrypt these messages should also be developed to thwart all threats to both security and 
privacy. Numerous problems similar to the security issues of an IP network and DNS can affect 
the overall ICN architecture. The DNS QNAME minimization type of approach would be 
suitable for preserving privacy in the name resolution process. Therefore, security 
mechanisms such as accessibility, authentication, etc., for the NRS system [RFC9138] should be 
considered to protect not only the NRS system but also the ICN architecture overall. 
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